Multimedia Broadcast and Multicast Services, MBMS, is a broadcasting service offered via cellular networks. Enhanced MBMS (eMBMS) is used to denominate MBMS service in Evolved Packet Systems including Evolved Universal Terrestrial Radio Access Network, E-UTRAN, for Long Term Evolution (LTE), cellular networks and UTRAN for e.g. Universal Mobile Telecommunications System (UMTS) cellular networks. One example of an eMBMS over LTE solution architecture is illustrated in FIG. 1. The architecture 100 of FIG. 1 comprises at least one Broadcast Multicast Service Center (BM-SC) 110, which is capable of distributing content provided from one or more content service providers 120, where a content service provider 120 typically comprise a content store (not shown) and a live encoder (not shown) capable of providing content feeds e.g. in the form of satellite feeds, live feeds and/or Content Delivery Network (CDN) feeds, to the BM-SC 110 under supervision of a Broadcast operations function 130, which is typically capable of interacting with the BM-SC 110. The BM-SC 110 is connected to an access network, typically comprising a plurality of access nodes, but for simplicity here represented by one single access node, eNB 140, via a Multimedia Broadcast Multicast Services Gateway (MBMS-GW) 150, where the eNB 140 is capable of distributing the provided content feeds to User Equipments (UE) located within range of the access network, via unicast or multicast. Here such UEs are represented by one single UE, UE 160.
In order to be able to remedy failure to receive the content feeds correctly at at least one of the UEs, the architecture is typically also provided with functionality, enabling the BM-SC 110 to re-transmit parts of the content feeds to those UEs 160 reporting failure to receive at least parts of the content feeds. Such a feature is typically referred to as File repair, or more specifically HTTP Unicast File repair. For enabling file repair, the BM-SC 110 is therefore normally provided with at least one, but typically with a plurality of file repair servers (not shown), capable of providing lost or corrupted file fragments of the content feeds to requesting UEs, by way of re-transmission.
The purpose of a file repair procedure is to repair lost or corrupted file fragments, packets or symbols from the MBMS download data file broadcast transmission. When in multicast/broadcast environment, scalability becomes an important issue as the number of UEs, grows. From hereinafter UEs may also be referred to as MBMS clients, since the mentioned UEs are restricted to UEs capable of handling MBMS and/or EMBMS. Three problems should generally be avoided when applying file repair:                Feedback implosion due to a large number of UEs requesting simultaneous file repairs. This would congest the uplink network channel.        Downlink network channel congestion to transport the repair data, as a consequence of the simultaneous MBMS clients' requests.        File repair server overload, caused again by the incoming and outgoing traffic due to the clients' requests arriving at the server, and the server responses to serve these repair requests.        
In order to avoid file repair server overload, 3rd Generation Partnership Project, 3GPP TS 26.346 proposes two methods:                Spread the file repair request load in time. The MBMS client calculates a random back-off time. The sending of the file repair request message from the UE to a file repair server shall start at Back-off Time=offset-time+Random Time. The UE shall calculate a uniformly distributed Random Time out of the interval between 0 and Random Time Period. The random time period is indicated by a randomTimePeriod parameter in an Associated Delivery Procedure Description, (ADPD) sent from BM-SC to UEs        Spread the file repair request across multiple file repair servers. A list of file repair service URIs is provided as elements of the Associated Delivery procedure fragment's postFileRepair element. The MBMS client randomly selects one of the service URIs from the list, with uniform distribution.        
A typical lifecycle of one file repair procedure is illustrated in FIG. 2. When one file repair procedure is triggered, UEs may send file repair (FR) requests in a time slot decided by randomTimePeriod 210, following an offset time 200.
When a UE creates a HTTP connection and sends a file repair request to a file repair server via this connection which may arrive during time interval 220, the connection will be kept for some time, defining the complete file repair procedure 230, allowing the UEs to download symbols, or repair symbols, from the file repair server.
Consequently, after the randomTimePeriod 210, no UE will send FR requests but some FR connections will be kept until the UEs have downloaded all the repair symbols they need.
3GPP TS 26.346 V9.5.0: MBMS Protocols and codecs and 3GPP TS 23.246 V9.5.0: MBMS Architecture and functional description have both proposed how to spread the traffic of single file repair procedure in time and across multiple servers. But the file repair servers still may be overloaded because of extreme bad LTE network situation and file repair burst traffic caused by multiple file repair procedures which have time overlap.
In FIG. 3, there are two file repair procedures 300 and 310 illustrated for two different data file download sessions which have part time overlap. As a UE calculates a uniformly distributed random time to send file a repair request for a file repair procedure, the resulting traffic 320 (file repair requests per second) of file repair procedure 300 or 310 should be uniformly distributed in time. But the total traffic increases twice in the overlapped time slot, i.e., the burst traffic happens in the time slot when the two file repair procedures are time overlapped, as is illustrated with resulting traffic 320.
The more file download sessions that are being delivered, the more file repair procedures may have this type of time overlap and the more extreme burst traffic may happen. There are some ways for operators to handle burst traffic. One way is to schedule the file repair procedures for each file download carefully to avoid time overlap. This way has two obvious shortcomings: a) increase the difficulty of scheduling (sometime it is even impossible if there are too many concurrent file downloads and file repair procedure is quite long); b) file repair server resource waste because the ratio of MBMS clients which need file repair and the ratio of symbol loss may vary quite differently. Another way is to deploy enough file repair servers to service extreme burst traffic. Obviously this way will, however, bring high file repair server resource waste.
When file repair servers are overloaded, they will respond to a FR request by sending an HTTP 503 response, also referred to as service unavailable or service not available, to the UEs. Unfortunately other UEs do not know that the file repair servers are overloaded and keep sending FR requests.
The UEs who receive the HTTP 503 response may retry sending a FR request after some time but they don't know how long time they should wait. If they retry according to a configured time, they may receive a HTTP 503 response again because the file repair servers may still be overloaded.
As mentioned above, there are a plurality of problems that may arise due to UEs sending file repair requests.